home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / dcom / modems-part1 / 9321 / text0000.txt < prev   
Encoding:
Text File  |  1996-08-05  |  3.4 KB  |  60 lines
  1. On Tue, 26 Mar 1996, Bob Nixon wrote:
  2.  
  3. > Appology accepted, I admittedly don't understand the inner workings of how 
  4. > Win-95 handles the com ports or if the DTE settings above 115200 are real 
  5. > but concerning the mutitasking while moving files both in and out plus 
  6. > Bi-directional transfers here are my nunbers for single and by-directional 
  7. > transfers of highly compressable files while running a DOS graphics based 
  8. > game running in demo mode in the background. My system is AMD486DX4-120 
  9. > w/32megs of ram and Diamonds Stealth-32 graphics card. The modem is USR 
  10. > Courier with V.34+ code. Tranfers for single or one way file transfer of a 
  11. > Coreldraw.cdr(border file) 10600cps both inbound and outbound with a 
  12. > 28800/28800 connection. Bidirections transfer slowed to about 8000cps on 
  13. > each direction. Both these numbers are nearly identical to the speeds that 
  14. > I've gotten on previous tests. BTW transfer method was WS-FTP32 with a 
  15. > Win-95 ppp connection to my ISP, Primenet in Phoenix, AZ at 9:30PM(busy 
  16. > prime hours) to my home directory.
  17. > 
  18. > PS. Comm overruns were not observed during any testing.
  19.  
  20. Ok, let me try to explain what's going on here. First, the modems between 
  21. the computers are controlling the transfer in conjunction with the CPU's 
  22. at each end. In addition, the 115200 DTE rate is bottle-necked down to 
  23. 28800 between the modems. This is true even though the throughput rate is 
  24. above 10600 cps. Why? you might ask. Well, the modems compress the data 
  25. first *before* sending it. This also helps explain why the throughput 
  26. in each direction drops when doing bi-directional transfers on 
  27. uncompressed files; the modems each are doing double-duty compressing and 
  28. uncompressing each data stream.
  29.  
  30. Your numbers pretty much match mine on modem to modem transfers both in 
  31. uni-directional and bi-directional transfers. I presume you used HS/Link 
  32. for the bi-directional (and, from the rates on uni-directional, probably 
  33. on those also)? I need to try this with Smodem (in my opinion, a more 
  34. efficient and fault-free bi-directional protocol) and see what I get on a 
  35. bi-directional transfer with that.
  36.  
  37. Now, if you have two computers, hook up a null modem cable between them 
  38. and open each port at 115200. Take a file and transfer it. That was my 
  39. bench test for comparison between the linux and DOS platforms. No modems, 
  40. no LapLink, just two comm programs (Commo on one side and minicom on the 
  41. other) using zmodem (DSZ at one end, the built-in zmodem at the other)
  42. I would be interested to see results of a 230k port setting at each end 
  43. with DOS or Win95 at each end also.
  44.  
  45. The tests were made in one direction only; from the DOS box to the 
  46. linux/DOS box, with the linux/DOS box booted to DOS and then booted to 
  47. linux. When the linux/DOS box was in DOS, the comm program was Commo 
  48. w/DSZ as the zmodem protocol drive (also did it with DSZ as a standalone).
  49.  
  50. Again, I am not using Win95 but I do know a little about that platform. 
  51. It isn't really a true operating system, it runs on DOS 7.0 so it's 
  52. subject to similar problems that any DOS box might have. It is, I am 
  53. informed, much improved over Windows 3.1 (and WFWG 3.11) but I still see 
  54. complaints about throughput and overruns.
  55.  
  56. What amazed me about linux was the absolute lack of errors during a true 
  57. hi-speed transfer (115200 from end to end). I was used to limiting the
  58. DOS-to-DOS connections to 57600 in order to limit the errors during transfer.
  59.  
  60.